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PREFACE (U) 


The purpose of this project development plan is to define how the ACIS 
computer system will be developed from initiation through completion. The 
intent is to ensure that all relevant management and technical issues are 
fully considered, and that provision is made for an orderly, systematic 
development of the project. It will also provide management with a control 
mechanism by enabling and making visible a comparison between planned 
versus actual project progress. 
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EXECUTIVE SUMMARY (U) 


This document provides an outline, for both project and higher level 
management, of the methods and schedule by which the ACIS computer system 
will be developed. The ACIS project will require significant amounts of 
manpower and machine resources, and it will be necessary to phase in 
project deliverables over a period of several years. Thus, this document 
will be updated periodically, and the information contained herein will be 
correct only as of the most recent cover~sheet date. 


Managing a large developmental project such as ACIS is a routinely complex 
undertaking, and the use of a proven methodology is a prerequsite for 
project success. ACIS will utilize a structured methodology based upon the 
most recent works of Metzger, supplemented where appropriate from other 
sources. The methodology will guide the project throughout the entire 
developmental life-cycle. This cycle will consist of the following phases: 
requirements definition, preliminary and detail design, programming and 
unit testing, integration and system testing, acceptance testing, 
installation, and actual operation of the new system. To the extent that 
outside contractors or commercial packages are used, the phases will be 
slightly different. At present, ACIS is in the requirements definition 
phase of the developmental life-cycle. 


This document is arranged in ten general categories that includes an 
introduction and a detailed discussion of the project life cycle. 
Organizational relationships are also discussed to ensure that normal 
inter-component coordination is achieved. Details are provided on the 
approach to product testing at various stages of completion, as well as on 
the proposed independent quality assurance program. A convenient listing 
of all formal project documentation is provided, and will be maintained in 
a current fashion available for management review. Training activities will 
be given a high level of visibility because of its importance to ultimate 
developmental success and customer satisfaction. A series of formal and 
periodic management reviews is also provided to enable management to 
exercise the appropriate level of control given the eventual size of the 
project. Finally, the document discusses actual operation of the system 
and provides specifics on the resources, deliverables, and target 
completion dates. 


At present, activity can only be scheduled through 2 October 1981 because 
the resources required to develop ACIS have not been finalized by 
management. A major decision needs to be made as to whether the project 
will be developed entirely in-house, or by contractor personnel. Another 
decision relates to the advisability of using a commercial payroll package. 
These decisions will be made by the 2 October date at which time it will be 
possible to schedule activities a greater distance into the future. 
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1. INTRODUCTION (U) 


1.1 BACKGROUND (U) 


This plan will provide specific information for both management and the 
project development team. This plan identifies: 


oO The products to be developed. 


fo) The development resources required 

re) Schedules for formal progress review. 
fe) Internal project milestones. 

re) Product. phased-delivery milestones. 
fe) Organizational relationships. 


° Reporting relationships. (U) 


This plan will be executed and the system implemented by following the 
methodology defined by Philip W. Metzger in his book "Managing a 
Programming Project". The methodology will be modified, where necessary, 
to meet our unique needs. It will also be supplemented where appropriate 
from other sources (e.g. FIPS PUB 38 and the work of Burrill and Ellsworth 
from their book on Modern Project Management). (U) 


It should be noted that this document is designed to be a planning tool. 
As such, it charts a high-level path for both immediate and long-term 
development. A supporting document, known as the Detail Work Plan (DWP), is 
also used by project management, but at the day-to-day working level in 
which tasks are scheduled and individually assigned in a finely detailed 
manner. The DWP is mentioned only for purposes of reference, and is not 
included within the PDP. Both the PDP and the DWP will be modified and 
updated as appropriate to meet the dynamic requirements of the system 
development process. (U) 


1.1.1 CURRENT PAYROLL (P/R) SYSTEMS (U) 


The payroll function within the Agency has been divided into four distinct 
payroll systems. These are as follows: 
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° The automated Biweekly Payroll system which pays [ 25X11 


percent of all persons employed by the Agency. 


oO CIA Retirement and Disablility System (CIARDS) pay system. 
° Joint Publications Research Service (JPRS) pay system. 


Detailed discussions of each of these four systems may be found in the 
Functional Requirements Document (FRD). The Biweekly payroll system's 
basic functions are described below in some detail because it is the most 
important system, and because all of the Agency's payroll systems possess 
these same basic functions to some extent. Brief overviews of the 
remaining three payroll systems are also provided to draw the important 
distinctions between the Biweek system and the three remaining systems. (S) 


1.1.2 BIWEEKLY PAYROLL OVERVIEW (U) 

The current biweek P/R system was first put into use in 1973, and has 
undergone significant modification during the subsequent 8 years. The 
primary function of the biweek system is to pay Agency employees. (U) 

It pays employees on the basis of hours worked, and it does so within the 
strict confines of the normal two week payroll processing cycle. The 
system performs a routine but critical function. If serious system 
problems develop, the impact can potentially have Agency-wide ramifications 
within a short period of time. (U) 

The system is comprised of seven major modules which are. as follows: 


re) Time & Attendance input processing 


o Master file update 


fe) Final Review/Corrections 

fe) Pay computation 

re) Reporting/history 

.e) Actual payments 

fe) Year-end processing. (U) 
SECRET 
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1.1.2.1 Time & Attendance Input Processing (U) 
25X1 


The Agency time and attendance record (T&A) is used to record regular hours 
in pay status, hours for additional compensation , and leave hours used. 


cards are manually processed by Compensation Division every two weeks. 
This is considered to be an unsatisfactory aspect of the system. In 
addition to the obvious inefficiencies, there is a growing risk that 
extensive manual processing may overwhelm the users with predictable 
consequences for the timely compensation of Agency employees. (3S) 


After keypunching, the T&A data is run through an edit process. Edit 
reports are produced and provision is made for user corrections as 
necessary. Additional processing occurs which, among other things, 
identifies missing and duplicate T&As. The appropriate reports and 
opportunities for correction are provided at this point. (U) 


1.1.2.2 Master File Update (U) 


ae The master file contains all of the basic information with which the 

w payroll system is concerned such as employee name, employee number, pay 
grade, types of deductions, etc. There are over 200 separate data items in 
the master file. It is the most important file in the system and it is 
extremely sensitive in that it identifies essentially every employee in the 
Agency. The data items contained in this file are defined by certain data 
identification codes. Maintenance is performed on this file by using 
another seperate set of codes known as transaction codes. (C) 


Updates to this file can originate from a number of different sources, and 
they are accomplished either mechanically or manually. Update sources 


include: 


fe) Office of Personnel (PERSIGN system) 


fo) Compensation Division 

° Insurance Branch 

fe) Credit Union 

° Voluntary Investment Plan (VIP) Administrator 
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° Consolidated Fund Campaign 
fe) The employee directly. (S) 


Maintenance to the master file is batched , keypunched and hash totals 
reviewed prior to actual processing by the system. An update program is 
run that performs additional editing functions such as format checks, code 
validations against the master file's allowable codes, and balancing type 
routines. The update processing routines provide over 20 maintenance 
reports to assist compensation personnel in monitoring at a detailed level 
all changes made to the master file. The system of update controls with 
respect to this file is a critical key to the integrity of the payroll 
system. (C) 


1.1.2.3 Final Review/Corrections (U) 


During normal circumstances, most employees work a regular scheduled tour 
of duty, accrue set rates of leave and are paid a constant amount for long 
periods of time without any changes. However, between 15-25 per cent of 
Agency employees will require some type of special handling or pay/leave 
adjustments during any given pay period. While most of these adjustments 
are relatively simple, some can be quite confusing and complex. This 
module is where the current system handles the special cases encountered. 


(C) 
The types of special adjustments handled covers a variety of cases and 
combination of cases. Some cases are handled in an automated manner while 
others require some degree of manual intervention. A brief set of 
illustrative examples is provided: 

oO Amended Té&As 

fe) Sick leave advance requests 

fe) TDY post differentials 

fe) Hazardous duty pay 

fe) Moving expense claims 

fe) Suggestion awards, etc., etc. (S) 
Trained payroll technicians become directly involved in the pay and leave 
adjustment process. They must spend considerable time in completing 
various input documents to submit for final payroll system processing. This 
direct intervention is approaching unacceptable limits. (S) 
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1.1.2.4 Pay Computation (U) 


This module consists of numerous computer programs that actually compute 
the earnings, deductions and allowances applicable to each employee. This 
is accomplished by using master file data, validated T&As, and pay/leave 
adjustment inputs. The process consists of two broad functional steps: 1) 
base hours to gross pay, and 2) gross pay to net pay. The appropriate 
distinctions are made between taxable and non-taxable pay. The entire 
process is controlled and closely reviewed. (U) 


1.1.2.5  Reporting/History (U) 


Historical information is maintained in six general areas. They are as 
follows: 


fe) Savings bond history 

° Federal and state tax history 

fe) Comprehensive year-to-date history 
fe) Retirement systems history 


So 
re) Leave history. (8) 


These areas are not exclusive in that they are simply different 
summarizations of the same extensive data maintained in the system's master 
file. In addition, normal input validation, update, and summarization type 
reports are routinely produced in every payroll cycle. (S) 


1.1.2.6 Actual Payments (U) 

Net pay entitlements are produced on magnetic tapes for EFT and Treasury 
checks respectively. Treasury's production of Agency salary checks is 
performed at that installation on a prearranged schedule. (5S) 

1.1.2.7 Year-end Processing (U) 

Among the year-end processes are the various tax reports and employee W-~-2 
forms. In addition, processing occurs for separation pay cases and 


initializations for running totals prior to the start of the next year's 
cycle. (S) 
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1.1.4 CIARDS OVERVIEW (U) 


The present CIARDS system was established in 1968. Its overall purpose is 
to pay former employees who have retired under the Agency's retirement 


system. (U) 


The basic functions of CIARDs are very similar to those of the Biweek 
System except that CIARDS is much simpler by comparison. Several notable 
points concerning CIARDS are listed below: 


o Annuitants are paid in amounts that are relatively stable and 
fixed. 


o A distinction is made between non-taxable equity and taxable 
amounts paid. 


o Deductions are typically limited to insurance and credit union 
matters. 
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o Cost-of-living adjustments are periodically factored in at one time 
for all annuitants. (U) 


1.1.5 JPRS OVERVIEW (C) 


JPRS overall purpose is to pay independent contractors who perform foreign 
language services, primarily translations, for the Agency. (U) 


The basic functions of JPRS are very similar to the Biweek system. By 
comparison, JPRS is a simpler system. Several notable points concerning 
JPRS are listed below: 


o The system only pays independent contractors. 


o Year-end tax reporting is done through a manual interface with the 
General Accounting System. 


o Contractors are paid on a monthly basis, typically on a "piecework" 
basis. 


o Checks are prepared manually. (C) 


The basic functions and desirable features of the current payroll systems 
will serve as a starting point for the future ACIS system. ACIS will 
differ from the current systems in two significant and broad areas that can 
be summarized as follows: 


fe) A variety of new features will be provided that will increase the 
overall effectiveness of the Agency's compensation system. 


° There will be an increase in the overall efficiency in the 
administration, operation, and query capability of the 
compensation system. (U) 


A specific area of change will be the manner in which T&A data is entered 
into the biweek system. Instead of the essentially manual approach now 
used, this process will be automated to the maximum extent feasible 
consistent with external regulatory requirements. (U) 


Another area of change will be the manner in which information is made 
available to operational personnel and management. An extensive query 
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capability will be provided to enable rapid satifaction of user's 
information needs as they arise. (U) 


A third area of significant change will be the manner in which changing 
requirements and user's needs affect the system. The new system will 
incorporate top-down structured code and modular design concepts to 
facilitate future modifications and enhancements. Users will thus find 
ACIS to be an extremely flexible system. (U) 


Because of the comprehensive scope of the project, resource constraints, 
and users' needs for system improvements, a staged project development 
approach will be adopted. The system functions therefore will not all 
materialize simultaneously, but rather be sequentially introduced. (U) 


1.3 PROJECT OBJECTIVES (U) 
The overall objective of the project is to enhance the ability of the 
Office of Finance to perform its mission of financial support to Agency 
components, particulary in the the area of payroll processing. This will 
be primarily accomplished by providing the Office of Finance with a 
comprehensive, state-of-the-art automated compensation and management 
information system. Related project subobjectives are as follows: 


fe) Improve the productivity of Compensation Division by automating 
the payroll functions to the maximum extent feasible. 


fo) Provide comprehensive information to Management concerning the 
payroll function. 


fe) Provide this information in a timely and, where appropriate, 
instantaneous manner. 


° Reduce the present high level of demand upon the Office of Data 
Processing for data entry services and system modification 


requests. 


fo) Enhance information available to Management by interacting 
automatically with other financial systems, where feasible. 


fo) Provide a capacity for readily meeting future demands for growth 
and enhancements. (U) 
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1.4 POTENTIAL CONSTRAINTS (U) 
The purpose of this. subsection is to identify in general terms problems or 
potential problems as they are detected on the planning horizon that may 
impact the ACIS project. The intent is to identify problems as early as 
possible so that they may be obviated or the system design modified, as 
appropriate. (U) 


In addition to satisfying the requirements needed by Compensation Division 
to effectively operate the Agency's compensation system, ACIS must also 
satisfy the requirements of other interested entities, some of whom are 
external to the Agency. Potential problems could arise in that some of 
these entities may have conflicting requirements. (U) 


The General Accounting Office (GAO) prescribes requirements for financial 
Systems operated within the Executive Branch. One requirement that impacts 
the ACIS system is the current provision that all T&A type documents must 
be approved by an appropriate supervisory level person. This must be done 
before these documents can be forwarded for processing and any payments 
made to employees. A problem arises in that this effectively requires 
supervisors to physically sign the T&As, and for the signed hardcopies to 
be physically retained after payroll processing is completed. It would 
probably be more efficient to enter the T&A data in a purely electronic 
form, but some manner of hardcopy entry may have to be substituted in order 
to fully comply with GAO's requirement unless a waiver could be obtained. 


(U) 


Another area concerns the nature of the ACIS interface requirements. As is 
the case with the current system, ACIS will have to interface with over 10 
other Agency systems. Some of these interfaces will be manual, but most 
will be automated. Two of the larger systems with which ACIS will 
interface are the General Accounting System (GAS) and the Integrated 
Personnel Management System (PERSIGN). Given that automated interfaces 
have the potential of significantly complicating systems development, and 
to the extent that present or future systems may impose unique or arcane 
interface requirements in order for ACIS to effect a complete interface, 
certain design tradeoffs may have to be made. At present, no significant 
problems have been detected, and none are presently expected. (U) 


An additional area of potential impact concerns the staged delivery 
approach discussed briefly in Section 1.2. The three primary factors that 
require a staged approach are: 


fe) Resource availability 


fe) Compensation Division's needs 
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fe) Scope of the project. (VU) 


To the extent that any or a combination of these factors significantly 
changes, the staged delivery schedule may have to be appropriately 
adjusted. (U) 


1.5 PROJECT DEVELOPMENT OPTIONS (U) 


There are currently three options that can be foreseen for the development 
of the ACIS system. The three options are to develop the ACIS system (1) 
using personnel in-house (staff or staff/contract), (2) using an outside 
contractor to deliver the total system, or (3) by purchasing an existing 
commercial payroll package and having it tailored to our specific needs. 
The types of resources available to develop ACIS will be decided upon by 2 
October 1981 after which time one of the above three options will be 
selected for ACIS. (AIUO) 


Each of these three options are considered within the PDP whenever it is 
deemed that they have a significant impact. In particular Sections 2, 4, 
and 10 show the alternate plans as they affect the development cycle; test 
and evaluation; and resources, deliverables, and schedule respectively. 
(AIUO) 


1.6 SCOPE (U) 


This document is organized into the following ten major sections: 


° Section 1," Introduction", presents the purpose and scope of the 
ACIS Project Development Plan. 


) Section 2," Project Development Cycle", describes the set of 
sequential phases that constitute the project methodology. ACIS 
will be completed by progressing through these various phases 
over the life cycle of the project. 


fe) Section 3, "Organization and Responsibility", describes the 
various organizations involved in the development of ACIS. The 
roles and functions of each are identified. 

ro) Section 4, "Test and Evaluation", describes the various levels 


and types of ACIS product testing used to ensure that all system 
components meet the required specifications. 
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fo) Section 5, "Quality Assurance", describes the project quality 
control program, and how it will function as an ongoing, 
independent subgroup organized to ensure that proper software 
engineering practices and standards are followed. 


° Section 6, "Documentation", describes the formal documents to be 
produced in support of the ACIS system development, 
implementation, and operation. 


3) Section 7, "Training", identifies the specific areas and the 
manner in which members of the project development team will be 
trained to facilitate the development effort. User training 
requirements will also be addressed to ensure that they 
understand how to operate the ACIS system. 


Oo Section 8, "Reviews and Reporting", discusses the set of formal 
and informal review procedures and appropriate control points 
needed to ensure a smocth and continuous process of system 
development progress. 


Oo Section 9, "Installation and Operation", descibes in greater 
detail the procedures by which the system will actually be 
installed and implemented. 


Oo Section 10, "Resources, Deliverables, and Schedule", summarizes 
the personnel staffing required to develop and implement ACIS. 
Data Processing factors are discussed, and a detailed near-term 
schedule that identifies the timing of ACIS deliverables is also 
provided. (U) 


1.7 APPLICABLE DOCUMENTS (U) 


The following is a list of the formal ACIS documents produced to date: 


o ACIS Project Development Plan dated 2 July 1981. (U) 


1.8 PDP DOCUMENT MAINTENANCE (U) 


This document is intended for use by ODP management. The document will be 

revised periodically to ensure that the information it contains is the most 
current possible. The document will not be placed under ACIS configuration 
control. (U) 
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Written comments, corrections, and suggestions are welcome and should be 
addressed to: . 
AGIS Project Manager 


Seren ere Division 


This document is intended for limited distribution. Requests for copies 
may be sent to the above address. (U) 
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2. PROJECT DEVELOPMENT CYCLE (U) 


The project development methodology to be used to develop the Automated 
Compensation and Information System (ACIS) is briefly discussed in the 
following paragraphs. As previously mentioned alternate cycles are shown 
based upon whether ACIS is developed in-house, by a contractor, or by 
tailoring a commercial payroll package. This decision is driven by 
availability of resources which will be determined by 2 October 1981. 
Regardless of the option selected, the development cycle of ACIS will 
follow an orderly set of discrete phases each having a defined goal, set of 
deliverables, and completion point. These logical breakpoints are called 
milestones or baselines and are useful in measuring progress, determining 
quality, and ensuring sufficiency of the resulting system. The reviews 
that are scheduled at each of these milestones are discussed in Section 
8.1. (U) 


The Project Initiation and Requirements Definition Phases are (a) common to 
all the options; (b) occur between project start on 23 March 1981 and the 
resource decision point on 2 October 1981; and (c) consist of the 
following: 

A Project Initiation Phase (U) 

The Project Initiation Phase lays the groundwork on which the project is to 
be developed. This phase defines the project development cycle to be 
followed and the controls to be placed upon the development cycle (Project 
Development Plan-PDP). (U) 


In addition to the production of the PDP, other activities to be performed 
in this phase are: 


fo) Organize and staff an ACIS project group within "C" Division/ODP 
including personnel from both. ODP and OF. 


oO Determine the budget requirements. 
fo) Establish a working relation with the audit staff of the 
Inspector General's Office to identify and resolve critical 
issues concerning system integrity, security, and auditability. 
fe) Inform all affected parties/offices of ACIS plans. (U) 
B Requirements Definition Phase (VU) 


The Requirements Definition Phase determines the functional requirements to 
be satisfied by ACIS. The major output of this phase is the Functional 
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Requirements Document (FRD) which also forms the basis for the contractor 
Request For Proposal (RFP) if required. Sources for this document will 
include the following: 


re) Request for change enhancements submitted for the current payroll 
systems that for various reasons will not get incorporated. 


fe) Descriptions of the functions performed by the current payroll 
systems as found in design, development, and current systems 
documents. 

fe) Interviews with other personnel including OF staff/users of the 


current systems. (U) 


In addition to the Functional Requirements Document (FRD), requirements 
must be determined for system interfaces (e.g., PERSIGN), database elements 
and structure, communications, and hardware. (U) 


2.1 IN-HOUSE DEVELOPMENT CYCLE (U) 


This cycle assumes that the system is developed in-house, whether by staff 
only or staff augmented with contracted expertise. Under either of these 
staffing plans the following phases apply. (AIUO) 


2.1.1 DESIGN PHASE (U) 


The System Design Phase provides the analysis, design, and review processes 
necessary to determine the hardware and software structure that can best 
satisfy the user's requirements. (U) 


The major products of this phase are the Preliminary System Design 
Specifications and System Design Specifications. The ACIS project team 
will be responsible for preparing the Preliminary System Design 
Specification and the Detailed System Design Specification. (U) 


Two reviews will be performed for the customer in the System Design Phase: 
the Preliminary Design Review (PDR) and the Critical Design Review (CDR). 

The project team will be responsible for the preparation and presentation 
of these reviews. (U) 


Upon completion of the Critical Design Review (CDR), any changes to the 
system design will follow the procedures outlined for Configuration 
Control. (U) 
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2.1.2 PROGRAMMING AND UNIT TEST PHASE (U) 

All programming, unit testing, and program documentation will be done by a 
development group under the ACIS project management team. The programs 
will be documented internally and externally according to standards 
described for ACIS Configuration Control. (U) 


2.1.3 INTEGRATION AND SYSTEM TEST PHASE (U) 

All testing performed after the software has been turned over following 
unit testing will be done by a separate test team. The purpose of testing 
is to independently assess whether the product fulfills/meets objectives. 
A detailed discussion of Integration and System testing may be found in 
Sections 4.1.2 and 4.1.3. (U) 


2.1.4 ACCEPTANCE TEST PHASE (U) 


The acceptance test phase within the system development cycle is designed 
to. demonstrate to the customer that the system satisfies his requirements 
as originally specified. Acceptance testing is discussed in Section 4,1.5. 


(U) 


2.1.5 INSTALLATION AND OPERATION PHASE (U) 
This phase of the project cycle will address the installation of the new 
system in a production like environment, the conversion from the current 
system to the new, and the daily operation and maintenance of the new 
system. Depending upon the quality of the system developed and the type of 
data formats required, the conversion effort could either become a large 
effort (i.e. a mini-project) or be a small effort. If conversion is a 
large effort, it will be planned in detail, and be accomplished in phases 
similar to those of the ACIS project as a whole. 


2.2 CONTRACTOR OR COMMERCIAL PACKAGE CYCLE (U) 

The phases for ACIS system development assuming a contractor developed 
system or a commercial payroll package are basically the same. Hither 
option is assumed to produce a complete system which must be verified as to 
how well it satisfies the requirements. On-going monitoring will be 
performed during the life cycle up to delivery to the government. The 
following two phases will then be performed at that point. (AIUO) 
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2.2.1 INSTALLATION PHASE (U) 


This phase of the project cycle will address the installation and parallel 
testing of the system on Agency computer systems and any related 
modifications/additional testing required. It will also address the 
conversion of existing data files. This effort will most likely be 
considerable, and the contractor will be expected to employ a methodology 
to ensure the successful accomplishment of this phase. (U) 


2.2.2 ACCEPTANCE TEST PHASE (U) 


The acceptance test phase is designed to demonstrate that the system 
performs according to specifications and satisfies the functional 
requirements. (U) 
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3. ORGANIZATION AND RESPONSIBILITY (U) 


3.1 ACIS USER ORGANIZATION (U) 


The ACIS system is being developed for the Office of Finance (OF) to aid 
them in carrying out their charter of developing and maintaining an Agency 
financial system to reflect and report on the status, use, and 
accountability for all funds, property, and other assets for which the 
Director of Central Intelligence (DCI) is responsible. Figure 3-1 displays 
the organizational structure of OF. The remainder of this section 
describes the responsibilities of the OF organizations affected in some way 
by the development of the ACIS system. (C) 


3.1.1 OF POLICY AND PLANNING STAFF (U) 


The Policy and Planning Staff is responsible for: 


fe) Assisting and advising the Director of Finance in the day to day 


management of OF as it relates to policy, planning, systems, and 
evaluations. 

fe) Developing and recommending Agency fiscal policies and 
procedures. 

ro) Furnishing technical guidance and assistance in all matters of 


finance and accounting policy. 


fe) Conducting reviews and evaluations of current and proposed 


finance and accounting systems to ensure integrity and currency. 
(C) 


3.1.2 OF COMPENSATION DIVISION (U) 


Compensation division is the primary customer for the ACIS system. ACIS 
will be designed and developed to aid them in providing overt and covert 
payroll activities for Agency personnel. This includes: (1) the issuance 
of W-2 forms, (2) year end reports consistent with unique Agency cover 
arrangements, and (3) ad-hoc queries related to Agency compensation 
activities. (C) 
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ACIS PROJECT ORGANIZATION (U) 


The ACIS project is within "C" Division of Applications, under the Office 


of Data Processing (ODP) within the CIA Directorate of Administration 


(DDA). 


Figure 3-2 displays the organizational structure of the DDA. 


Figure 3-3 displays the organizational structure of ODP. (U) 


3.2.3 


"Cc" DIVISION (U) 


The Chief and Deputy Chief of "C'' Division have responsibility for: 


1@) 


fo) 


3222 


Management review of the ACIS project 

Approval authority over the ACIS configuration 

Preparation and revision of the annual ACIS Resource Package 
Reporting to the Deputy Director of Application, Director of ODP, 
and the Director of OF on the status of the ACIS Project 
Development Schedule and on long range planning and budgetary 
considerations as they relate to ACIS 

Intra-office and inter-office/directorate coordination support as 


required by the ACIS project. (U) 


ACIS PROJECT GROUP RESPONSIBILITIES (U) 


The ACIS Project Group is responsible for the development of the ACIS 


System. 


The ACIS Project Manager will be responsible for: 


fe) 


fe) 


Management of the group 

Review of all ACIS plans 

Progress tracking of all ACIS activities 

Budget support and financial controls 

Prioritizing ACIS tasks within schedule constraints 


Reporting ACIS activities to the Chief, C Division and senior 
Agency management 
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The ACIS Project Group will be responsible for some or all of the following 
functions consistent with the development cpticn selected: 


a. 


Requirements and Analysis 


Data collection 

Analysis of current processes and activities 
Technology versus requirements tradeoffs 
Feasibility studies (if necessary) 
Preliminary estimates 

Preliminary cost justification 

Preliminary system design 


Systems Development 


Hardware analysis and recommendations 

Commercial software analysis and recommendations 
Database design 

Detailed system design 

Communications analysis and recommendations 
Programming and unit testing 

Program: and system level documentation 
Conversion and transition 


System Testing 


Testing tools generation 

Integration testing 

System testing 

Performance testing 

Test plan, specification, and procedures generation 
Test reporting 


Quality Assurance 


Configuration Management: 

Audits/Independent Verification and Validation 
Coordination of external interfaces to ACIS 
Documentation control 

Resource management 

Software library management 

Release management 

ACIS central library management. (U) 
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3.2.3 ACIS DEVELOPMENT AUTHORITY (U) 


The management responsibility for the development, maintenance, and 
operation of ACIS rests with the Office of Data Processing (ODP) in 
response to requirements levied by the Office of Finance. Within ODP, 
project responsibility has been assigned to the ACIS Project Manager within 
"Cc" Division of Applications. (U) 


3.3 ACIS SUPPORTING ORGANIZATIONS (U) 
ACIS will be designed, developed, and implemented completely internal to 


the DDA and as such will obtain support as determined necessary from within 
ODP and other DDA components. (U) 
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4. TEST AND EVALUATION (U) 


Software Test and Evaluation (T&E) is a continuous and integral part of the 
development process. Its objectives are: 


‘e) To ensure compliance with all design requirements and 
constraints. 
fe) To ensure the adequacy and correctness of the software products 


(i.e. evaluating the product's performance). 


This process will apply to all baseline software products developed for the 
production systems. 


The goal of software testing is software that meets the requirements as 
stated. Close coordination is essential between the developer and the 
tester throughout the life cycle of a software item to ensure the 
development of test cases that thoroughly exercise new and modified 
software. 


Software testing consists of the following five phases. Each phase has 


specific organizational responsibilities. 


° Unit Testing 


fo) Integration Testing 
fe) System Testing 

° Interface Testing 

o Acceptance Testing 


As software passes from one test phase to another, the test results and 
documentation will be reviewed for accuracy and completeness. (U) 


4.1 IN-HOUSE TEST & EVALUATION 


4.1.1 UNIT TEST (U) 


Unit testing is defined to include: 


fe) Proving accuracy of computations. 
_O Showing repeatability of results. 
SECRET 
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fo) Testing upper, lower, and nominal ranges of data values. 
fe) Verifying data handling characteristics under normal and adverse 
conditions. 
fe) Thoroughly exercising every new or changed routine of every 


module and function within a computer program. 


fe) Verifying the proper transmission of data between routines, 
modules, and functions within a computer program, i.e., 
interfaces. 


Unit testing is the responsibility of the development group, and will be 
accomplished by the programmer who develops or modifies a particular 
software program. Test data may be provided by the programmer, or data may 
be used which has been accumulated by the development organization in a 
unit test data pool. Identification of tests conducted and copies of test 
results will be retained and become a part of the test documentation for 
the program. (U) 


4.1.2 INTEGRATION TEST (U) 

The objective of integration testing is to verify the interfaces between 
programs as specified in the design specifications. The responsibility for 
integration testing rests with the independent test group. 

Integration Testing is defined to include: 

° Verification of proper interface between programs which either 
depend on the output of other programs or which share data sets 
or data. 

° Verification of satisfaction of requirements placed on the 
interaction of functions between programs by the System Design 
Specification. 

Integration testing will be conducted from the test software libraries or 


test database(s), using as far as possible a standard set of self-contained 
baseline test cases. (U) 
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4.1.3 SYSTEM TEST (U) 


The objective of system testing is verification of the system's performance 
and functional capabilities to meet the stated requirements as traceable 
from the FRD. The responsibility for system testing rests with the 
independent test group. 


System testing includes the following activites: 
° Following the flow of data into the system. 
fe) Tracking the data through the major pathways of the system. 
fe) Verifying the data output by the system. 


System testing will be conducted from the test software libraries or test 
databases, using a standard set of self-contained baseline test cases as 
far as possible. (U) 


4.1.4 INTERFACE TEST (U) 


Interface tests and demonstrations will be conducted between the system and 
all external systems with which it communicates. The purpose of these 
tests is to verify the compatability of the communication interface between 
the system and the sending and receiving parties as well as the correctness 
of the data transferred. The responsibility for planning, coordinating, 
scheduling, and conducting these tests rests with the independent test 
group supported by the customer as required. These tests can occur for a 
product that is in the system test phase. Successful completion certifies 
that the interface is correct. (U) 


4.1.5 ACCEPTANCE TEST (U) 


This phase of testing will validate test cases and test data which have 
been developed in conjunction with the customer. The responsibility for 
planning and insuring the completion of acceptance tests rests jointly with 
project personnel from OF and ODP. The responsibility for conducting, 
analyzing, and documenting acceptance tests rests with the customer. (U) 


4.2 CONTRACTOR OR COMMERCIAL PACKAGE T&E (U) 


Since the ACIS system will be delivered as a complete unit under these 


options the test and evaluation will consist of acceptance testing to 
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ensure that the system performs as required. The responsibility for 
conducting these tests will rest with OF and ODP. (U) 
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5. QUALITY ASSURANCE (U) 


The goal of Quality Assurance (QA) is to assure overall system quality with 
respect to usability, reliability, maintainability, testability, and 
accountability. QA ensures that the product being designed and developed 
satisfies the following: 


fe) The product meets user requirements during each stage of the 
system development cycle. 


fe) The requirements are traceable from conception through the cycle 
to final product delivery. 


fe) The product meets specified performance criteria. 


fe) The product is developed in a logical, coherent manner and 
conforms to existing standards and procedures. (U) 


The objectives of QA are addressed through the following methodologies: 

° Configuration Management (CM) 

° Audit/Independent Verification & Validation (IV&V) 

° Test & Evaluation (T&E) 

fe) Standards and Procedures 
The following sections define the detailed QA to be followed for the in- 
house development option. If one of the other two options is selected, 
these QA criteria would be looked for in the development methodologies of 
the contractor and would be applied once the product is installed on Agency 


computer systems. Test and Evaluation has been described in Section 4. and 
the others are described in the following paragraphs. (U) 


5.1 CONFIGURATION MANAGEMENT (U) 


Configuration Management (CM) is a discipline which applies technical and 
administrative management to the identification and documentation of the 
characteristics of an item; controls changes to those characteristics; 
records and reports the status of change processing and implementation; and 
conducts audits to verify conformance to specifications, drawings, and 
documents. (U) 
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5.1.1 CONFIGURATION MANAGEMENT BENEFITS (U) 


The application of configuration management provides the following tangible 
benefits: 


fe) It provides visibility of the entire data processing system and 
its up-to-date status for planning and costing purposes. 


fo) It limits expenditure of resources to authorized changes in the 
software or interrelated system elements. 


° It provides a basis for computer software test planning and test 
design, leading to maximum software reliability and performance. 


° It reduces the problem of integrating software with equipment, 
personnel, operations, and facilities. 


fo) It improves the basis for system management of the entire 
software development process. 


fe) It improves the accuracy, currency, and completeness of the 
approved documentation which describes the computer program end 
item. 

re) It provides visibility of the entire system for evaluating the 


effect of proposed changes to the software or to other 
interrelated systems and interfacing systems. (U) 


5.1.2 CONFIGURATION IDENTIFICATION (U) 


Configuration identification is the process of defining and documenting the 
configuration of a system or another end item throughout its life cycle. 
The first step in this process is the identification of the Configuration 
Item (CI). CIs are an aggregate of equipment or computer programs that 
satisfy an end-use function and are designated for configuration 
management. The configuration of each CI is documented through the use of 
specifications and other design documents. This documented configuration 
becomes the baseline for the CI and the basis for configuration control and 
status accounting. (U) 
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5.1.3 CONFIGURATION CONTROL (U) 


Configuration control is the systematic evaluation, coordination, and 
approval or disapproval of proposed changes to any baseline. Formal 
control of the configuration of an item or system begins with the 
definition and approval of a baseline for the item and continues through 
completion of the life cycle. Subsequent to the approval of a baseline for 
an item or system, all changes to that baseline must be proposed in the 
form of a Request for Change (RFC). These RFCs are formally reviewed and 
approved or disapproved by a Configuration Control Board (CCB). (See 
Section 5.1.5 for further detail on the CCB.) (UV) 


5.1.4 CONFIGURATION STATUS ACCOUNTING (U) 
As a result of the configuration identification and control, an item's 
configuration is identified and changes to that configuration are proposed, 
evaluated, and implemented. Keeping track of the configuration 
identification and its changes and reporting this information are the 
functions of a CM tracking system. (U) 


The following two major types of status accounting documents are produced 
by the CM tracking system: 


CONFIGURATION LISTS These lists define the current approved 
configuration of an item in terms of its 
elements or identification documents and its 
approved changes. , 


CHANGE STATUS REPORTS These reports give the implementation status 
of changes to a configuration item. (U) 


These status accounting documents provide implementing personnel and 
management with visibility and traceability of baseline configurations and 
their changes. They give implementing personnel the means to coordinate 
the many actions that must be performed in support of changes, and they 
give management the means to determine if change decisions are being 
implemented as directed. (U) 


5.1.5 CONFIGURATION CONTROL BOARD (U) 


Configuration control is the process by which changes to software, 
documents, and products are initiated, evaluated, approved or disapproved, 
implemented, verified, released, and documented. This process, which 
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provides controlled updating of the evolving system configuration, assures 
complete analysis of changes that affect cost, schedule and design. (U) 


The Configuration Control Board (CCB) has responsibility for configuration 
control, is chaired by ODP with OF in attendance, and includes the 
following functions: 


° Review, evaluation, and approval or rejection of proposed changes 
to the configuration which address the following subjects: 


1. The establishment of and subsequent changes to baseline 
documents. 


2. The current production system software. 
3. The hardware environment and system software. 


oO Consideration shall be given to the desirability of the change 
and the benefits to be derived from it; its impact on current 
users, current schedules, and cost; its administrative or 
technical necessity; and feasible alternatives such as a 
workaround procedure if the change is not approved. 


° Establishment of the final priority assigned to a proposed 
change. This includes the opportunity to readjust the priorities 
of outstanding non-scheduled change requests at the beginning of 
each scheduling period. (U) 


5.1.6 CONFIGURATION AUDITS (U) 


Configuration audits are formal comparisons of the configuration 
identification against the configuration items (CI) which it depicts. 
Configuration audits are normally required for each developed CI or 
developed modification to a CI. There are two types of configuration 
audits, functional and physical. The Functional Configuration Audit 
(reference paragraph 5.1.6.1) is concerned with whether the CI will perform 
as intended. The Physical Configuration Audit (reference paragraph 

5.1.6. 2) is concerned with whether the CI physically matches the final "as 
built" documentation. In hardware development, these two audits are 
accomplished at different times; however, in software development it is 
feasible to accomplish both audits at once. (U) 
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5.1.6.1 Functional Configuration Audit (FCA) (U) 


A FCA verifies that the performance achieved by the product during 
validation testing (unit, integration, and system testing) is the 
performance required by the development specification. If integration and 
system testing are necessary to fully verify a product, the FCA is not 
completed until that time. The Project Manager or designee is responsible 
for conducting a FCA as required'to obtain formal customer signed 
acceptance of software products and documentation. (U) 


5.1.6.2 Physical Configuration Audit (PCA) (U) 


A PCA verifies that the configuration achieved in the product is accurately 
specified in the product specification and thereby establishes the product 
baseline. Preliminary reviews of computer operator's manuals, program 
maintenance manuals, and any similar document also are conducted at a PCA; 
formal acceptance of these manuals’ usually is withheld until system 
testing. The Project Manager or designee is responsible for conducting a 
PCA as required to obtain formal customer signed acceptance of products and 
documentation. (U) 


5.2 AUDITS/INDEPENDENT VERIFICATION AND VALIDATION (IV&V) (U) 


The purpose of Audit/IV&V is to verify that the following criteria are 
being met: 


fo) The project/system is technically valid. 


oO The objectives are clearly stated. 

fe) The requirements are satisfied and are traceable. 

fe) The system satisfies the intent of the originator (i.e. 
sufficiency). 

o) The project/system complies with existing standards and 
procedures. 


oO The project/system has adequate CM and T&E. 


fe) Security practices are observed. 
° The project/system is complete, consistent, and unambiguous. (U) 
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fhe types of items covered in the Audit/IV&V process are documentation; 
software (applications & system) and hardware; interfaces; transition; 
training; etc. A formal Audit/1IV&V should occur at each of the 
milestones/baselines. On-going Audit/IV&V functions occur throughout the 
project life cycle. (U) 


5.3 STANDARDS AND PROCEDURES (U) 
A set of standards and procedures are required to ensure that independently 
developed elements of a system have a common basis, appear to have been 
developed as a whole, and are easily maintained. These standards and 
procedures will cover the following areas: 

fo) Software 


o Documentation. (U) 


There are three major reasons for adopting a set of standards and 
procedures: 


re) To develop a product that is characterized by high degrees of 
reliability, readability, and maintainability. 


oO To promote practices that aid in the consistent and orderly 
development of the total system within schedule and budgetary 
constraints. 

fo) To meet the system design specifications. (U) 


The methodology to be used for developing ACIS software will be that of top 
down design/development, program modularization, and structured flow 
(sequential control). The developers will utilize the software development 


’ tools of structured walk-throughs, programming standards, code reading, and 


unit testing in the development of all ACIS software. The Project Manager 
or his designee will be responsible for seeing that these tools are used 
effectively. (U) 


The methodology to be used for developing ACIS documentation will be to 
define outlines for each unique document. These outlines will be followed 
by all authors to ensure document consistency, readability, and 
completeness. The Project Manager or his designee will be responsible for 
seeing that these tools are used effectively. (U) 
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6. DOCUMENTATION (U) 


The following documents should be produced during the project cycle by 
either the in-house ACIS project team or by the contractor if procured as a 
system. Automated documentation techniques such as SCRIPTX will be used if 
ACIS is developed in-house for the following documentation where 
appropriate. The ACIS Library will be the repository for these documents. 
The presence of "(CC)" in the descriptions below imply that the document 
will be placed under Configuration Control. (U) 


6.1 REQUIREMENTS DOCUMENTATION (U) 


fe) ACIS Project Development Plan - summarizes immediate and long 
term plans for ACIS development. 


fe) ACIS Functional Requirements Document - user requirements on 
which ACIS will be designed. (CC) 


re) ACIS Master Data Elements List - list of all data elements for 
ACIS together with descriptions and formats. (CC) (U) 


Kony 
Ih 


DESIGN DOCUMENTATION (U) 


ve) ACIS Preliminary System Design Specification - initial 
description of the overall system design alternatives; includes 
design and implementation cost estimates, resource requirements, 
development milestones, and test specifications. (CC) 


° ACIS Interface Control Documents - interface specifications 
between ACIS and other ADP systems (e.g. PERSIGN, CENCO, etc.). 
Depending on the size of the interface descriptions, they may be 
included as an integral part of the design specifications. (CC) 


fe) ACIS System Design Specifications - detailed description of the 
overall system design; includes functions and flow, performance 
requirements, file specifications, and test procedures. (CC) (U) 


lov 
[us 


PROGRAM DOCUMENTATION (U) 

fe) ACIS Program Manual - detailed documentation on all system 
software; contains complete program/database level documentation 
needed to perform maintenance on the operational software. (CC) 


(WU) 
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6.4 TEST DOCUMENTATION (U) 
fe) Test Plans - specify the purpose, goals, and overall description 
of the testing to be performed and the schedule for completion. 
(CC) 
fe) Test Specifications - provide a detailed description of what 


functions/programs are to be tested. (CC) 


fo) Test Procedures - provide a detailed description of how the tests 
will be performed and detailed test cases to be executed during 
validation and acceptance testing. 


(CC) 
fe) Test Reports - present observations and conclusions obtained from 
the execution of the test cases. 
(CC) (U) 


6.5 USER DOCUMENTATION (U) 


fe) ACIS User Manual - instructs the user in how to execute ACIS 
procedures; serves as reference manual for user. (CC) (U) 


|ov 
an 


OPERATIONS DOCUMENTATION (U) 


fo) ACIS Operating Procedures Manual - instructions required for 
those portions of the system that may require direct intervention 
of the computer operator (e.g, backup). (CC) (U) 
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IN 


TRAINING (U) 


7.1 OVERVIEW (U) 


This section identifies the training activities needed to develop and 
implement ACIS. Training activities are divided into two broad categories: 
1) project team training, and 2) user training. Project team training will 
be required to develop and deliver a quality system, and will be conducted 
during the initial and middle phases of the project. User training will be 
needed to help users acquire an understanding of and maximum effectiveness 
from the new system. User training will be concentrated in the latter 
phases of the project. (U) 


The two subsections that follow will provide detailed information on the 
areas for which training will be conducted within each of the two broad 
categories just discussed. The training required, scheduled dates for 
training, and other relevant information will be provided as this 
information becomes known. Since much of this information is subject to 
change, the information provided below can be considered up-to-date only as 
of the date shown on the cover sheet to this Project Development Plan. (U) 


7.2 PROJECT TEAM TRAINING (U) 
At least four areas may require some degree of formal training. These 
areas are payroll design, database management systems, the COBOL computer 
language, and hardware familiarization courses. 


7.2.1 DESIGN COURSE (U) 


Courses are offered that present optimum design information that has been 
collected during the development of commercial payroll systems. This type 
of data is invaluable and will be made available to the ACIS project team. 
The course selected is American Management Association's "Automated Payroll 
Systems Design Course" to be attended on 26-28 October 1981. (AIUO) 


7.2.2 DBMS TRAINING (U) 


ACIS will employ some type of database management system and it will be 
necessary for certain members of the project team to have the requisite 
DBMS skills. At present, the type of DBMS to be used has not yet been 
determined, and thus training details are not yet defined. (U) 
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7.2.3 COBOL TRAINING (U) 


There are a number of payroll application packages available on the 
commercial software market. If one of these packages is selected for use 
with ACIS it will most likely require some degree of COBOL training since 
most of the commercial packages are written in COBOL. (U) 


7.2.4 HARDWARE FAMILIARIZATION (U) 


It is possible that ACIS may require certain hardware or other specialized 
equipment to satisfy user requirements. To the extent that this is 
necessary, some form of hardware familiarization training will be required, 
most likely to be provided by the vendor. (U) 


7.3 USER TRAINING (U) 


Three probable areas of user training can be identified at this point. 
These are T&A input procedures, database update procedures, and database 
query procedures. These areas provide a starting point and will be 
considerably expanded at the appropriate time. These areas are briefly 
discussed below. (U) 


7.3.1 T&A PROCEDURES (U) 


These procedures will be changed considerably when ACIS is delivered. In 
addition to the operating personnel in Compensation Division, approximately 


[T&A clerks throughout the Agency will have to be trained in the new 


input procedures. This will pose a logistical problem of some magnitude 
that will have to be effectively addressed prior to implementation. (U) 
7.3.2 DATABASE UPDATE (U) 

ACIS will probably utilize a database management system in lieu of the 
current file structures. While functionally similar, update and 
maintenance procedures will be significantly different. This will require 
retraining of user personnel. (VU) 

7.3.3 QUERY (U) 

A query capability will be a new feature of the ACIS system. . Training will 


have to be provided in order for the user to take full advantage of the 
powerful capabilities that this feature will offer. (U) 
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8. REVIEWS AND REPORTING (U) 


Reviews and reports constitute checkpoints at which progress on a project 
may be evaluated. At each of these checkpoints a defined set of 
information is made available for review and evaluation by project internal 
management and/or the customer. Completion of a scheduled review is 
visible evidence that a given milestone was achieved. Reporting records 
project activities, plans, and problems together with whether the 
milestones are achieved behind, ahead of, or on schedule. (U) 


Section 8.1 below lists the reviews that are planned for the ACIS project 
and Section 8.2 lists the levels of reporting planned together with the 
type and frequency of the reports. (U) 


8.1. REVIEWS (U) 


|co 
fay 


.1 FORMAL REVIEWS (U) 


8.1.1.1 Functional Requirements Review (U) 
The purpose of the functional requirements review is to review the problem 
specifications, system and data requirements, and project development plan 
to determine the readiness to commence the system/project design, 
development, and implementation. This review is an on-going process during 
the definition phase that culminates with a formal review among the 
customer and the developing organization. The approved functional 
requirements become the baseline for the preliminary design. They are 
placed under configuration control. (U) 


8.1.1.2 Preliminary Design Review (PDR) (U) 
The purpose of the Preliminary Design Review (PDR) is to review the 
Preliminary System Design Specifications (PSDS) and the Test Specification 
Document to determine the readiness to progress to the Detailed Design 
Phase. The PDR ensures that all requirements are included in both 
documents and that both documents agree on the requirements. Critical 
dates for the exchange of information and/or data between the interfaces 
are established. An informal review including the designer, the 
programmer, and the tester should be held prior to the formal review. The 
formal review will include the customer, project management, the designer, 
the programmer, and the tester. The customer and project management must 
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approve the PSDS and the Test Specification Document. Both documents will 
be placed under configuration control. (U) 


8.1.1.3 Critical Design Review (CDR) (U) 


The purpose of the critical design review is to review the System Design 
Specification (SDS) and the Test Procedure Document to determine the 
completeness and adequacy of the baseline design and the readiness to 
progress to the code phase. Software design is presented to demonstrate 
compliance of the design to the requirements. Test procedures are 
presented to ensure that all test specifications are included. An informal 
review should be held prior to the formal review and includes the designer, 
programmer, tester, and those project personnel who are technically 
competent to verify the design. The formal review includes the above 
persons as well as project management and the customer. The customer and 
project management must approve the System Design Specification Document 
and the Test Procedure Document. Both documents will be placed under 
configuration control. (U) 


8.1.1.4 Code Review (U) 
The purpose of the code review’ is to review each module to ensure 
compliance with the System Design Specification and to verify that 
established programming standards are met. The review includes the 
designer, a senior programmer, the programmer who did the eodias and a 
programmer from the independent test group. (U) 


8.1.1.5 Unit Test Review (U) 


The purpose of the unit test review is to review the unit test results and 
program documentation to ensure readiness of the software to be passed to 
the test team. The review process includes the programmer, tester, and 
applicable project managers. (U) 


8.1.1.6 Integration/System Test Review (U) 


The purpose of this review is to review the integration/system test results 
to ensure that the software was tested in accordance with the Test 
Procedure Document. The review includes the tester and applicable project 
managers. (U) 
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8.1.1.7 Acceptance Test Review (U) 
This review will be conducted by the customer to review acceptance test 


results to ensure that the software satisfies their requirements as 
originally specified. (U) 


8.1.1.8 Post-Mortem Review (U) 

The purpose of this review is to review the software development 
methodology to determine areas for improvement. The review is a critical 
analysis of the project and is held after the software has become 


operational. The review includes the designer, programmer, tester, project 
management, and customer. (U) 


8.1.2 INFORMAL REVIEWS (U) 
Informal reviews may be held at any point within the development cycle. 
Attendees at such reviews will usually consist of project personnel and 
outside experts as required by the review. 
The informal review techniques utilized should include: 

° Peer review 

fo) Structured walkthroughs 
The responsibility for scheduling an informal review and establishing the 
list of attendees resides with the Chief of the organization involved or 


with the Project Manager as appropriate. 


Reasons for holding informal reviews include the following: 


° To determine whether a proposed design meets the design 
requirements. 
fe) To determine whether the proposed method of implementation is 
optimal. 
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fe) To consult with people who may have additional insight into the 
problem and its solution. 


re) Develop solutions for a given problem. (U) 


Kes) 
No 


REPORTING (U) 


8.2.1 OFFICE OF FINANCE REPORTING (U) 


OF analysts will be members of the ACIS project team and therefore it is 
assumed that OF will be kept informed of project status by these analysts. 
In addition, formal briefings of project status have been scheduled for the 
Directors of Data Processing and Finance to be given at their regularly 
scheduled monthly meetings. (U) 


8.2.2 OFFICE OF DATA PROCESSING REPORTING (U) 

Each Office of Data Processing (ODP) Division must prepare a weekly 
activity report. ACIS activities will be included in the "C" Division 
Weekly Report. All Division reports are consolidated into a single 
Applications Division report for the Director of ODP.In turn, the 
Director/ODP prepares a report for the DD/A. (U) 
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9. INSTALLATION AND OPERATION. (U) 
9.1 SYSTEM INSTALLATION PHASE (U) 


Project personnel will be responsible for installing the operational 
version of the ACIS software and performing the required data conversions 
and initializations necessary to ensure that the ACIS system is consistent 
with the systems it replaces. (U) 


9.2 SYSTEM OPERATION PHASE (U) 


"Cc" Division/ODP will manage the'development and maintenance support to the 
application software. "C" Division will provide a maintenance chief who 
will be on call around-the-clock and who will be responsible for resolving 
ACIS system problems. The functions of the maintenance chief will be to 
identify the source of system problems as they occur, determine the 
severity of the problem, contact that individual who can resolve the 
problem, and follow up on the solution to the problem. (U) 


Production Division/ODP will monitor system activity, run production jobs 
for the users, and execute utilities such as database backups and 
restorations. (U) 

Pay Administration Branch/Compensation Division/OF will be the users' point 


of contact for all ACIS system activities. The ACIS Data Base 
Administrator will be a member of the Pay Administration Branch. (U) 
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10. RESOURCES, DELIVERABLES, AND SCHEDULE (U) 
10.1 PERSONNEL (U) 


10.1.1 SKILLS AND EXPERIENCE FOR IN-HOUSE DEVELOPMENT (U) 

The skills and experience levels required for successful in-house 
development of ACIS change as development progresses through distinct 
phases. Between each phase there is a period of overlap during which the 
skills of both phases are required. Section 2.1 of this document describes 
the types of activities to be performed in each development phase. The 
following is a list of skills and experience requirements for each: 


o. During the Project Initiation (Section 2.1.1) and Requirements 
Definition (Section 2.1.2} phases the primary skills required are 
systems analysis, requirements analysis, and project management. 
Underlying these skills is the need for both broad and deep 
experience in developing computer system requirements, and the 
writing skills to document and express these requirements. 
Secretarial support is required, especially in the area of word 
processing. 


re) During the Design phase (Section 2.1.3) the skills required are 
systems analysis, system design, and project management. A 
detailed state-of-the-art knowledge of computer systems 
architecture and software engineering is mandatory. A limited 
amount of programming support will be needed for analysis, 
simulation, and testing to validate design decisions. 
Secretarial support is required, especially in the area of word 
processing. 


fe) During the Programming and Unit Test phase (Section 2.1.4) the 
skill level needed is a mix of intermediate to senior level 
programmers and system designers. Project Management skills are 
also required, as is secretarial and word processing support. 


fe) The Integration and System Test phase (Section 2.1.5) effort 
requires a mix of intermediate to senior level software testers 


and administrators. Project management skills are also required, 
as is secretarial and word processing support. 
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fe) The Acceptance Test phase (Section 2.1.6) effort also requires a 
mix of intermediate to senior level scftware testers and 
administrators. Project management skills are also required, as 
is secretarial and word processing support. 


fo) During the System Installation and Operation phase (Section 
2.1.7) the amount of programming skills required decreases and 
the amount of integration skills increases. Otherwise, the same 
types of skills as Programming and Unit Test (Section 2.1.4) are 
required. 


10.1.2 SKILLS AND EXPERIENCE FOR CONTRACTOR OR COMMERCIAL PACKAGE 


PROCUREMENT NT (U) 


The skills and experience levels required for successful procurement of a 
complete system are different from those required for a system developed 


- in-house. For this case a great deal of monitoring of the contractor is 


required up until delivery. This requires senior level Systems Analysts 
and Contract Monitors and Administrators. Project management skills are 
required as is secretarial support. The acceptance test and installation 
phases require skill mixes as mentioned under these headings in Section 
10.1.1 above. (U) 


10.1.3 STAFFING SCHEDULE (U) 
During the Project Initiation (Section 2.1.1) and Requirements Definition 
(Section 2.1.2) phases the ACIS team will consist of senior managers from © 
Division/ODP and the Policy and Plans Staff/OF. Secretarial support will 
also be required. Additional staffing plans are contingent upon the 
development option selected. (U) 


10.2 DATA PROCESSING ENVIRONMENT (U) 


The ACIS system development and operation will require the use of Agency 
computer systems. The details cannot be adequately determined at this time 
however it is probable that VM plus a mainframe CPU using PL/I and a DBMS 
language will be required. (U) 


10.3 ° SCHEDULE (U) 


The ACIS near term schedule (until 2 Oct. 1981) is presented below. 
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fo) FRD 2 Oct 1981 
o Analyses "2 Oct 1981 
The impact of the three development options makes it undesirable to 
propagate the schedule further than 2 Oct. 1981 at this time. (U) 
10.4 DELIVERABLES (U) 
° ACIS Functional Requirements Document, to be published in DRAFT 
form on 2 October 1981. 
. 
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